Document History
Changes to this Specification are coordinated by IHO NIPWG. New editions will be made available via the IHO web site. Maintenance of the Specification shall conform to IHO Resolution 2/2007 (as amended).
Table — Document History
| Version Number | Date | Approved By | Purpose |
|---|---|---|---|
1.0.0 | April 2012 | TSMAD | Approved edition of S-102 |
2.0.0 | March 2017 | S-102PT | Updated clause 4.0 and 12.0. |
#include::sections/01-overview.adoc[]
#include::sections/02-spec_scope.adoc[]
#include::sections/03-data_product_id.adoc[]
#include::sections/04-data_content_struct.adoc[]
1 Coordinate Reference Systems (CRS)
1.1 Introduction
The Coordinate Reference System information contained in Table 1-1 is defined in the manner specified in part=6. The vertical datum is specified separately using other root group attributes.
1.2 Horizontal Coordinate Reference System
Table 1-1 — S-102 Coordinate Reference Systems (EPSG Codes)
| EPSG Code | Coordinate Reference System |
|---|---|
| 4326 | WGS84 |
| 32601 — 32660 | WGS 84 / UTM Zone 1N to Zone 60N |
| 32701 — 32760 | WGS 84 / UTM Zone 1S to Zone 60S |
| 5041 | WGS 84 / UPS North (E,N) |
| 5042 | WGS 84 / UPS South (E,N) |
| The full reference to EPSG can be found at https://epsg.org. | |
- Horizontal Coordinate Reference System
EPSG (see Table 1-1)
- Projection
NONE/UTM/UPS
- Temporal reference system
Gregorian Calendar
- Coordinate Reference System registry
- Date type (according to [iso-19115-1])
002 — publication
- Responsible party
International Association of Oil & Gas Producers (IOGP)
- URL
1.3 Vertical Coordinate Reference System
Although in this product there are no direct vertical coordinates the values of the depth attributes are indirectly such coordinates. Therefore, it is important to specify the vertical CRS to which these values conform. The vertical CRS is an earth gravity-based, one-axis coordinate system. The Orientation of the axis is defined by the vertical coordinate system attribute (verticalCS) in the root group (see Table 6-2).
The vertical datum must be taken from the code-list specified by the IHO Geospatial Information (GI) Registry for the attribute named Vertical Datum. It will be defined in the root group as an HDF5 attribute (see Table 6-2).
1.4 Temporal reference system
The temporal reference system is the Gregorian calendar for date and UTC for time. Time is measured by reference to Calendar dates and Clock time in accordance with clause=5.4.4. A date-time variable will have the following 16-character format: yyyymmddThhmmssZ.
2 Data Quality
Data quality allows users and user systems to assess fitness for use of the provided data. Data quality measures and the associated evaluation are reported as metadata of a data product. This metadata improves interoperability with other data products and provides usage by user groups that the data product was not originally intended for. The secondary users can make assessments of the data product usefulness in their application based on the reported data quality measures.
2.1 Completeness
2.1.1 Commission
Commission is applicable for S-102. Data Producers must verify that no excess items have been included in the dataset. Such excess items include duplicate items, which must be removed.
If no excess items are present, the dataset PASSES this test.
2.1.2 Omission
Omission is applicable for S-102. Data Producers must verify that no items that should have been included in the dataset have been omitted.
If no necessary items have been omitted, the dataset PASSES this test.
2.2 Logical consistency
2.2.1 Conceptual consistency
Conceptual Consistency is applicable for S-102 and follows the guidelines from part=1.
Data Producers must verify that the dataset conforms to the S-100 General Feature Model.
If the dataset conforms to the S-100 General Feature Model, the dataset PASSES this test.
2.2.2 Domain consistency
Domain consistency is applicable for S-102 and follows the guidelines from part=5.
Data Producers must verify that the dataset conforms to the S-102 Feature Catalogue and to Annex A.
If the dataset conforms to the S-102 Feature Catalogue and to Annex A, the dataset PASSES this test.
2.2.3 Format consistency
Format Consistency is applicable for S-102 and follows the guidelines from part=10c.
Data Producers must verify that the dataset conforms to Section 6 of this Product Specification.
If the dataset conforms to Section 6, the dataset PASSES this test.
2.3 Positional accuracy
2.3.1 Gridded data positional accuracy
Gridded positional accuracy is defined by the precision of the positional reference used to specify its location within its spatial projection. These positional references are contained within the spatial metadata of the S-102 grid. It is assumed that any horizontal errors are assimilated into the vertical uncertainty. The vertical values are calculated for each grid point using the processes and procedures used by each hydrographic office during the creation of the S-102 grid. Appropriate selection of both the origin reference point and spatial resolution are important and are another factor in gridded positional accuracy.
2.3.2 Relative internal positional accuracy
The internal positional accuracy is defined as the precision of the location of each grid point within the S-102 grid. The position of each grid point within the grid is referenced by a row and column combination. The metadata for S-102 defines a gridded resolution along both the X and Y axis of the grid. This absolute position of a grid point within the spatial projection of the grid is calculated using the row/column and the X/Y resolution. In this case, the accuracy is controlled by the precision used in defining these resolutions.
2.4 Temporal accuracy
Temporal accuracy, consistency, and validity of bathymetric grids are confined to elements of the vertical control processes. These aspects are addressed during the formulation and application of vertical control processes applied by the various hydrographic offices. Details of these processes will be included in the Lineage portion of the metadata defined in Section 8 of this Product Specification.
2.5 Thematic accuracy
2.5.1 Thematic classification correctness
For S-102 bathymetric grids there are two classifications of data values, which are land and water. There are two considerations for assessing classification correctness when using the grid. The first is that values given in the depth layer of the S-102 grid are based on the associated hydrographic office’s chosen vertical datum. Should another value in relation to a different vertical datum be required, a series of correctors would need to be applied. Secondly, when considering the data values, the value stored in the uncertainty for a given grid point must be considered. This uncertainty value represents the magnitude of possible deviation in either direction from the data value and must be applied when assessing the classification correctness. The new value generated when applied may cause a change in the classification.
2.5.2 Non-quantitative attribute accuracy
Thematic accuracy of S-102 bathymetric data is wholly quantitative.
2.5.3 Quantitative attribute accuracy
As defined in part=4c the data quality for the depth coverage is also defined as a co-located optional coverage, which is the uncertainty. This value particularly refers to the vertical uncertainty at each grid point. The uncertainty coverage supports multiple definitions of vertical uncertainty.
See Table 6-9.
3 Data Capture and Classification
The DCEG describes how data describing the real world should be captured using the types defined in the S-102 Feature Catalogue. The DCEG is located at Annex A.
A number of sounding techniques are used to capture bathymetric data. It is permitted, but not required, to include data acquisition information in the metadata of an S-102 Bathymetric Surface product. The metadata class S102_AcquisitionMetadata has been defined, but the information elements to populate this metadata class should be identified in a national profile of S-102.
3.1 Quality and source metadata
Quality and source metadata in S-102 are intended to enable and support future navigation software to appropriately auto-generate and attribute cartographic features such as custom depth contours and soundings from S-102 products, all while minimally impacting the overall file size of the product.
Quality and source metadata are encoded in a feature attribute table compliant with both HDF5 and S-100. This feature attribute table will provide valuable information about the bathymetry on a grid cellwise basis compared to traditional vector-based metadata files, simplifying the interpretation and implementation by navigation software systems.
The fields of the feature attribute table are defined elsewhere in this Product Specification (Table 6-7).
Quality and source metadata in S-102 are based on S-101 quality attributes, with significant augmentations and omissions described below. The quality and source metadata support a threefold purpose:
Support S-101-defined attribution of auto-generated vector depth areas, depth contours, and soundings created directly from the S-102 dataset.
The attribute featureSizeVar is meant to augment featureSize which corresponds to S-101 size of features detected. As noted in S-101, size of features detected is intended to be described as the smallest size in cubic metres the survey was capable of detecting. Depending on various survey parameters, this definition might require different depth ranges to have different values. For example, a survey vessel working at a fixed height off the seafloor (such as an autonomous underwater survey vessel) could maintain a fixed feature detection size capability over a wide range of depths. Conversely, a surface vessel working over that same range of depths may have a feature detection capability that varies with depth. The latter situation could foreseeably cause the detection capability to be ambiguous and potentially misrepresented. For this reason, featureSizeVar is defined as the ratio (expressed as a percentage) of minimum detectable feature size to water depth. When both featureSize and featureSizeVar are present, the whichever value implies a larger feature size should be considered valid. The expectation is that featureSizeVar will be set to zero if the feature size does not scale with depth. As with featureSize, featureSizeVar should be ignored if significantFeatures is False.
Note that depth range maximum and minimum in S-101 are omitted. The assumption is that if this information is required, then the corresponding grid cells in the elevation layer can be queried for a minimum and maximum depth for each table row.
Provide necessary uncertainty information as an input into critical underkeel clearance precision navigation systems.
Prevent the automated selection of soundings from interpolated grid cells, while still providing the continuous data required for depth contour creation. This purpose is accomplished by the bathyCoverage Boolean attribute field. This field enables the flagging of grid cells populated by interpolation (when that interpolation occurs across gaps in bathymetric observations greater than the S-102 grid spatial resolution). This functionality is especially useful in side-scan surveys which are characterized by gaps in bathymetric observations with full coverage side-scan imagery. In this case, interpolated gaps between bathymetry coverage would show fullSeafloorCoverageAchieved = True and bathyCoverage = False. However, if fullSeafloorCoverageAchieved = False, bathyCoverage must also equal False (e.g., gaps between single beam echosounder data without correlating side scan sonar coverage). Thus, this facility will provide navigation software systems with the required information necessary to preferably select soundings from direct bathymetric observations.
Quality and source metadata are encoded as records within a featureAttributeTable dataset, which is itself within the QualityOfBathymetryCoverage container group (Table 6-7).
4 Data Maintenance
4.1 Maintenance and update frequency
Datasets are maintained by replacement on a dataset basis. That is, the entire data product and the associated metadata are replaced as a unit. This is unlike vector data that may be updated incrementally. Also, each replacement data set must have its own digital signature.
4.2 Data source
Data producers must use applicable sources to maintain and update data and provide a brief description of the sources that were used to produce the dataset.
4.3 Production process
Data Producers should follow their established production processes for maintaining and updating datasets.
5 Portrayal
5.1 Introduction
S-102 portrayal is intended to contribute to the safe operation of an S-100 based marine navigation system by:
Ensuring display of bathymetric surfaces, standards of colours, and their assignment to depths;
Ensuring the display is clear and unambiguous;
Establishing an accepted pattern for presentation that becomes familiar to mariners and so can be recognized instantly without confusion; and
Utilizing the S-100 portrayal model to ensure interoperability.
To ensure that presentation remains intuitive, the following principles must be followed when changes are made to the S-102 Portrayal Catalogue:
S-102 must maintain equivalence in terms of alerts and indications functionality in ECDIS;
The S-102 Portrayal Catalogue should be modified by extension. Portrayal rules should be retained for items that have been superseded in the current version of S-102. This retention ensures that S-102 data produced to previous versions can be displayed using the latest Portrayal Catalogue.
S-102 portrayal is covered by the portrayal model as defined in S-100. This model reflects how the Portrayal Catalogue is defined for use in marine navigation systems.
S-102 uses the portrayal processes defined in part=9 and part=9a. Items included in the S-102 Portrayal Catalogue must be registered in the IHO Geospatial Information (GI) Registry.
5.2 Portrayal Catalogue
Citation information for the S-102 Portrayal Catalogue is provided in Table 5-1 below.
Table 5-1 — S-102 Portrayal Catalogue Citation Information
| No. | ISO class or attribute | Type | Value |
|---|---|---|---|
CI_Citation | Class | ||
1 | title | Character String | S-102 Portrayal Catalogue |
2 | date | CI_Date | |
2.1 | date | DateTime | 2024-06-11T00:00:00 |
2.2 | dateType | CI_DateTypeCode | publication |
3 | edition | CharacterString | 3.0.0 |
4 | editionDate | DateTime | 2024-06-11T00:00:00 |
5 | citedResponsibleParty | CI_responsibility | |
5.1 | role | CI_RoleCode | publisher |
5.2 | party | CI_Organisation | |
5.2.1 | name | CharacterString | International Hydrographic Organization |
6 | otherCitationDetails | CharacterString | Found under: |
7 | onlineResource | CI_OnlineResource | |
7.1 | linkage | CharacterString | |
7.2 | name | CharacterString | S-102 Portrayal Catalogue |
7.3 | description | CharacterString | XML Portrayal Catalogue accompanied by related files for colour profiles, rules, etc. |
The S-102 Portrayal Catalogue contains the mechanisms for the system to portray information found in S-102 bathymetric surfaces. The S-102 Portrayal Catalogue contains the following types of mechanisms and structures:
Set of portrayal rules;
Set of colour profiles.
The Portrayal Catalogue model is defined in part=9,clause=9-13. The S-102 Portrayal Catalogue is available in an XML document, which conforms to the S-100 XML Portrayal Catalogue Schema. The structure for the Portrayal Catalogue is described in part=9,clause=9-13.2.
Figure 5-1 is included to illustrate informative depth zone colouring as adapted from S-52. More comprehensive portrayal details can be found in the S-102 Portrayal Catalogue, which is available in the IHO GI Registry (as detailed in Table 5-1).
Figure 5-1 — S-52, Edition 6.1(.1) Depth Zone Colouring for Day
5.2.1 Use of sun-illumination
S-102 data can be visualized as a sun-illuminated or static (flat) dataset. The depiction of sun-illumination requires the entry of a sun azimuth and corresponding elevation. Figure 5-2 shows the difference between a sun-illuminated and static (flat) surface.
NOTE Although sun-illumination provides marked benefit to the user, it is not currently supported by S-100. As such, it is advisable for ECDIS manufacturers to implement the facility of sun-illumination in order to make such a benefit available.
Informative values for sun azimuth angle and elevation have been provided in Table 5-2 below.
Table 5-2 — Sun Azimuth and Elevation Values
| Attribute | Value in Degrees | |
|---|---|---|
| Sun-Illuminated | Flat Surface | |
| Sun Azimuth Angle | 135 Degrees | 0.0 Degrees |
| Sun Elevation | 45 Degrees | 0.0 Degrees |
Figure 5-2 — Sun-illuminated and Static (Flat) Shading
6 Data Product Format (Encoding)
6.1 Introduction
The S-102 data set must be encoded using the Hierarchical Data Format standard, Version 5 (HDF5).
- Format Name
HDF5
- Version
1.8.8
- Character Set
UTF-8
- Specification
The key idea behind the S-102 product structure is that each coverage is a feature. Each of these features is co-located with the others. Therefore, they share the same spatial metadata, and each is required to correctly interpret the others.
For the use of HDF5, the following key concepts (part=10c,clause=5.1) are important:
- File
a contiguous string of bytes in a computer store (memory, disk, etc.), and the bytes represent zero or more objects of the model;
- Group
a collection of objects (including groups);
- Dataset
a multidimensional array of data elements with attributes and other metadata;
- Dataspace
a description of the dimensions of a multidimensional array;
- Datatype
a description of a specific class of data element including its storage layout as a pattern of bits; (Enumerations are encoded with unsigned 8-bit or unsigned 16-bit indices, depending on the number of transported values.)
- Attribute
a named data value associated with a group, dataset, or named datatype and stored as a scalar;
- Property List
a collection of parameters (some permanent and some transient) controlling options in the library.
In addition, datasets may be a compound (a single record consisting of an array of simple value types) and have multiple dimensions.
6.2 Product structure
The structure of the data product follows the form given in part=10c — HDF5 Data Model and File Format. The general structure, which was designed for several S-100 products is given in Figure 6-1.
Figure 6-1 — Outline of the generic data file structure
Figure 6-1 shows the four levels defined within the HDF encoding as defined in part=10c. Below is a further definition of these levels.
- Level 1
At the top level lies the Root Group, and it contains the Root Metadata and two subsidiary groups. The Root Metadata applies to all S-100 type products.
- Level 2
The next Level contains the Feature Information Group and the Feature Container Group. The Feature Information Group contains the feature BathymetryCoverage, the feature attribute codes and the optional feature QualityOfBathymetryCoverage. The Feature Container Group contains the Feature Metadata and one or more Feature Instance Groups.
- Level 3
This level contains one or more Feature Instance groups. A BathymetryCoverage feature instance is a bathymetric gridded data set for a single region and at a single vertical datum. A QualityOfBathymetryCoverage feature instance is a corresponding dataset for the same single region and for all applicable vertical datums.
- Level 4
This level contains the actual data for each feature. In S-102 BathymetryCoverage and QualityOfBathymetryCoverage each use the ValuesGroup to define the content. The other groups at this level are not used.
In Table 6-1 below, levels refer to HDF5 structuring (see Figure 6-1). Naming in each box below the header line is as follows: Generic name; S-100 or S-102 name, or nothing if none; and (HDF5 type) group, attribute or attribute list, or dataset. Figure 6-2 depicts the same structure using a graphical representation.
Table 6-1 — Overview of S-102 Data Product
| LEVEL 1 CONTENT | LEVEL 2 CONTENT | LEVEL 3 CONTENT | LEVEL 4 CONTENT |
|---|---|---|---|
General Metadata | |||
Feature Codes | Feature Name | ||
QualityOfBathymetryCoverage | |||
Feature Codes | |||
Feature Type | Type Metadata | ||
Feature Instance | Instance Metadata | ||
First data group | Group Metadata | ||
X and Y Axis Names | Bathymetric Data Array values | ||
Feature Type | Metadata | ||
QualityOfBathymetryCoverage.01 | Group_001 | Group Metadata | |
X and Y Axis Names | Quality of Bathymetry Data Array | ||
Feature Attribute Table |
Figure 6-2 — Hierarchy of S-102 Data Product
The following sections explain entries in Table 6-1 in greater detail.
6.2.1 Root Group
The root group is required by HDF5. The S-100 HDF5 format (part=10c) attaches metadata attributes applicable to the whole dataset to this group. S-102 uses all the S-100 attributes except geographicIdentifier and metaFeatures. The attributes used in S-102 are listed in Table 6-2, with specific requirements, if any, added in the Remarks column.
Table 6-2 — Root group attributes
| No | Name | Camel Case | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
1 | Product specification number and version | productSpecification | 1 | String | part=10c,table=6 |
2 | Time of data product issue | issueTime | 0..1 | String (Time format) | |
3 | Issue date | issueDate | 1 | String (Date format) | |
4 | Horizontal CRS | horizontalCRS | 1 | Integer | The identifier (EPSG code) of the horizontal CRS as defined in Clause 1.2 (see Clause 6.2.1, Note 2). |
5 | Epoch of realization | epoch | 0..1 | String | |
6a | Bounding box | westBoundLongitude | 1 | Float | The values are in decimal degrees. The root bounding box needs to encompass all data, including fill values. The outermost cell boundaries of the grid cells and the bounding box / domain extent polygon of each feature instance group form the basis for the root bounding box. |
6b | eastBoundLongitude | 1 | Float | ||
6c | southBoundLatitude | 1 | Float | ||
6d | northBoundLatitude | 1 | Float | ||
7 | Metadata | metadata | 0..1 | String | Name of metadata file |
8 | Vertical coordinate system | verticalCS | 1 | Integer | Mandatory in S-102. The only allowed value is: |
9 | Vertical coordinate base | verticalCoordinateBase | 1 | Enumeration | Mandatory in S-102. |
10 | Vertical datum reference | verticalDatumReference | 1 | Enumeration | Mandatory in S-102. |
11 | Vertical datum | verticalDatum | 1 | Integer | Numeric code from IHO GI Registry |
NOTE 1 The productIdentifier (“S-102”) and version fields (X.X.X) of S100_ProductSpecification must be used. NOTE 2 The value horizontalCRS specifies the horizontal Coordinate Reference System. At the time of writing, S-100 does not yet provide a mechanism for this value’s definition within HDF5 encoding (such as an enumeration of horizontal CRSs). Consequently, this configuration causes a deviation from S-100. The horizontal datum is implicitly defined by this CRS because each horizontal CRS consists of a coordinate system and a datum. S-102 does not use “user defined” CRS as mentioned in part=10c,table=6. NOTE 3 The baseCRS is the geodetic CRS on which the projected CRS is based. In particular, the datum of the base CRS is also used for the derived CRS (see part=6,table=6). NOTE 4 This is the default vertical datum. If and only if a BathymetryCoverage feature instance group does not specify a vertical datum, this (Root Group) vertical datum shall apply. | |||||
6.2.2 Feature Codes (Group_F)
No attributes.
This group specifies the S-100 features to which the data applies, and consists of three components:
featureCode — a 1-dimensional dataset with the featureCode(s) of the S-100 feature(s) contained in the data product. For S-102, the dataset has only two elements — the string “BathymetryCoverage” and “QualityOfBathymetryCoverage” (without quotes). The entries in this dataset give the names of the other two components of Group_F.
BathymetryCoverage — A 1-dimensional dataset that contains the standard definition of the bathymetry coverage feature class in terms of its attributes and their types, units of measure, etc. The datatype of its elements is the compound type described in part=10c,table=8.
QualityOfBathymetryCoverage — A 1-dimensional dataset of the same datatype as the BathymetryCoverage dataset described above. This QualityOfBathymetryCoverage dataset contains the definition of the reference to metadata records. The reference is a single integer which identifies a metadata record in featureAttributeTable (described in part=10c,clause=9.6.2 and Clause 6.2.8.
6.2.3 BathymetryCoverage and QualityOfBathymetryCoverage Tables (in Group_F)
BathymetryCoverage and QualityOfBathymetryCoverage are arrays of compound type elements, whose components are the 8 components specified in Table 6-3.
Table 6-3 — Sample contents of the BathymetryCoverage and QualityOfBathymetryCoverage arrays
| Name | Explanation | BathymetryCoverage | QualityOfBathymetryCoverage | |
|---|---|---|---|---|
S-100 Attribute 1 | S-100 Attribute 2 | S-100 Attribute 1 | ||
code | Camel Case code of attribute as in Feature Catalogue | depth | uncertainty | iD |
name | Long name as in Feature Catalogue | depth | uncertainty | ID |
uom.name | Units (uom.name from S-100 Feature Catalogue) | metres | metres | (empty) |
fillValue | Fill value (integer or float, string representation, for missing values) | 1000000 | 1000000 | 0 |
datatype | HDF5 datatype, as returned by H5Tget_class() function | H5T_FLOAT | H5T_FLOAT | H5T_INTEGER |
lower | Lower bound on value of attribute | -14 | 0 | 1 |
upper | Upper bound on value of attribute | 11050 | (empty) | (empty) |
closure | Open or Closed data interval. See S100_IntervalType in part=1. | closedInterval | geSemiInterval | geSemiInterval |
NOTE The uncertainty attribute of BathymetryCoverage may be omitted under certain conditions. See Clause 6.2.7. | ||||
According to part=10c,clause=9.5, “All the numeric values in the feature description dataset are string representations of numeric values; for example, “-9999.0” not the float value -9999.0.”
While the sample contents are shown in the two attributes columns, these are actually rows in the BathymetryCoverage table. They are also each a single HDF5 compound type and represent a single HDF5 element in the table.
All cells shall be HDF5 variable length strings. The minimum and maximum values are stored in lower and upper columns. Variable length strings allow future proofing the format in the event editing is allowed or correcting these values is required.
6.2.4 Root BathymetryCoverage
Table 6-4 — Attributes of BathymetryCoverage feature container group
| No | Name | Camel Case | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
| 1 | Data organization index | dataCodingFormat | 1 | Enumeration | Value: 2 |
| 2 | Dimension | dimension | 1 | Integer unsigned 8-bit | Value: 2 |
| 3 | Common point rule | commonPointRule | 1 | Enumeration | Value: 2 (low) see part=8,table=11. |
| 4 | Horizontal position uncertainty | horizontalPositionUncertainty | 1 | Float 32-bit | Value: -1.0 (if unknown or not available) |
| 5 | Vertical position uncertainty | verticalUncertainty | 1 | Float 32-bit | Value: -1.0 (if unknown or not available) |
| 6 | Number of feature instances | numInstances | 1 | Integer unsigned 8-bit | This is the total number of Feature Instance Groups within the Feature Container Group. The minimum is 1. see Clause 6.2.4, Note |
| 7a | Sequencing rule | sequencingRule.type | 1 | Enumeration | Value: 1 (linear) see part=8,table=12. |
| 7b | sequencingRule.scanDirection | 1 | String | Value: <axisNames entry> (comma-separated). For example, “latitude,longitude”. Reverse scan direction along an axis is indicated by prefixing a ‘-’ sign to the axis name. See [scanDirection] | |
| 8 | Interpolation type | interpolationType | 1 | Enumeration | Value: 1 (nearestneighbor). See part=8,table=13 |
| 9 | Offset of data point in cell | dataOffsetCode | 1 | Enumeration | Value: 5 barycenter (centroid) of cell. See part=10c,table=10 |
NOTE The number depends on the number of different vertical datums in the Feature Container Group. | |||||
6.2.5 Feature Instance group — BathymetryCoverage.nn
The BathymetryCoverage Feature Container Group can contain one or more Feature Instance Groups. The naming of the Feature Instance Groups follows the notation specified by the S-100. For generalization, the numbering is indicated with “.nn”.
Each feature instance group implements a unique vertical datum. All feature instance groups must share the same spatial location and extent. For each feature instance group, only the grid cells falling within the area of validity for that feature instance group’s vertical datum should be populated with (real) data. Within that feature instance group, all other grid cells should be populated with the fill value. Therefore, it is expected that:
The only grid cells that should be populated in more than one feature instance group are those that fall along a vertical datum boundary.
Where multiple population occurs, the ECDIS should choose the set of values resulting in the most conservative description to the mariner. (I.e., it should choose the shoalest adjusted depth.)
As derived from part=10c,clause=9.7 and part=10c,table=12, Table 6-5 and Table 6-6 describe the structure and attributes, respectively, of the BathymetryCoverage feature instance group.
Table 6-5 — Structure of BathymetryCoverage feature instance group
| Group | HDF5 Category | Name | Mult | Data Type | Remarks / Data Space |
|---|---|---|---|---|---|
| /BathymetryCoverage/ BathymetryCoverage.01 | attributes | (see Remarks) | 1 | (see Remarks) | Single-valued attributes as descripted in Table 6-6 |
| Dataset | domainExtent.polygon | 0..1 | Compound (Float, Float) | Spatial extent of the domain of the coverage Array (1-d): i=0, P Components: Either this or the bounding box attribute must be populated. | |
| /BathymetryCoverage/ BathymetryCoverage.nn | attributes | (see Remarks) | 1 | (see Remarks) | Single-valued attributes as descripted in Table 6-6 |
| Dataset | domainExtent.polygon | 0..1 | Compound (Float, Float) | Spatial extent of the domain of the coverage Array (1-d): i=0, P Components: Either this or the bounding box attribute must be populated. |
Table 6-6 — Attributes of BathymetryCoverage feature instance group
| No | Name | Camel Case | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
| 1a | Bounding box | westBoundLongitude | 0..1 | Float 32-bit | Coordinates should refer to the previously defined Coordinate Reference System. Either this or the domainExtent.polygon dataset must be populated |
| 1b | eastBoundLongitude | 0..1 | Float 32-bit | ||
| 1c | southBoundLatitude | 0..1 | Float 32-bit | ||
| 1d | northBoundLatitude | 0..1 | Float 32-bit | ||
| 2 | Number of groups | numGRP | 1 | Integer unsigned 8-bit | The number of data values groups contained in this instance group. Value: 1 |
| 3 | Longitude of grid origin | gridOriginLongitude | 1 | Float 64-bit | Longitude or easting of grid origin. Unit: (to correspond with previously defined Coordinate Reference System) |
| 4 | Latitude of grid origin | gridOriginLatitude | 1 | Float 64-bit | Latitude or northing of grid origin. Unit: (to correspond with previously defined Coordinate Reference System) |
| 5 | Grid spacing, longitude | gridSpacingLongitudinal | 1 | Float 64-bit | Cell size in x dimension. |
| 6 | Grid spacing, latitude | gridSpacingLatitudinal | 1 | Float 64-bit | Cell size in y dimension. |
| 7 | Number of points, longitude | numPointsLongitudinal | 1 | Integer unsigned 32-bit | Number of points in x dimension. |
| 8 | Number of points, latitude | numPointsLatitudinal | 1 | Integer unsigned 32-bit | Number of points in y dimension. |
| 9 | Start sequence | startSequence | 1 | String | Grid coordinates of the grid point to which the first in the sequence of values is to be assigned. The choice of a valid point for the start sequence is determined by the sequencing rule. Format: n, n Example: “0,0” (without quotes) |
| 10 | Vertical datum | verticalDatum | 0..1 | Integer unsigned 16-bit | see remark Table 6-2 row vertical datum and [mvdvdr] Mandatory for feature instance groups with a different vertical datum from that specified in the Root Group (prohibited otherwise) |
| 11 | Vertical datum reference | verticalDatumReference | 0..1 | Integer unsigned 8-bit | The only allowed value is 1: s100VerticalDatum (see part=10c,table=23). see [mvdvdr] Mandatory if this value were to differ from what is contained in the Root Group |
The gridOriginLongitude, gridOriginLatitude, gridSpacingLongitudinal, and gridSpacingLatitudinal attributes should be in the same geographic units as the bounding box. Note that this practice deviates from S-100 where it indicates that this value should be in Arc Degrees.
numPointsLongitude and numPointsLatitude must contain the number of cells in the x and y dimensions of the values table.
The S-102 uses the “Overriding of Attributes” concept of the part=10c,clause=9.7.1. This usage allows the feature instance group to overwrite the attributes of a higher group, in this case the verticalDatum. The default vertical datum is specified in the root group (see Table 6-2). The feature instance group for this default vertical datum must not use the additional attributes verticalDatum and verticalDatumReference (on the feature instance group).
If multiple vertical datums are present in the product, a separate feature instance group must be created for each vertical datum. These feature instance groups must use the additional attribute verticalDatum (on the feature instance group).
Note: At present, this Product Specification does not allow values other than 1: s100VerticalDatum for verticalDatumReference. However, if future changes allow the value of 2: EPSG (and if the value at the feature instance group differs from what is contained in the Root Group), then this value would become mandatory.
According to S-100, either the BoundingBox at the Feature Instance Group or the domainExtent.polygon must be specified. If domainExtent.polygon is specified, the BoundingBox is not specified in this case. The grid cells that do not belong to the area of the respective vertical datum should be assigned the fill value. If more than one domainExtent.polygon is used, those of different feature instance groups should not overlap. At positions where the polygons of different Feature Instance groups touch, the edges should be identical. The domainExtent.polygon does not have to follow grid cell boundaries but is an independent vector geometry based on the SoundingDatum surface from S-101. The domainExtent.polygon only supports a simple polygon geometry in accordance with part=10c,table=11. The mapping of multi-polygons and inner rings is not possible.
6.2.6 The values group — Group_001
This group contains 5 attributes, all of which are mandatory. According to part=10c,table=19, timePoint applies because the dataCodingFormat = 2. The other four attributes for this group are an extension of this Product Specification and, thus, are not defined by part=10c. Table 6-7 lists all 5 attributes.
Table 6-7 — Attributes of values group
| No | Name | Camel Case | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
| 1 | minimum Depth | minimumDepth | 1 | Float 32-bit | The minimum depth value in the values dataset(s) of this group |
| 2 | maximum Depth | maximumDepth | 1 | Float 32-bit | The maximum depth value in the values dataset(s) of this group |
| 3 | minimum Uncertainty | minimumUncertainty | 1 | Float 32-bit | The minimum uncertainty value in the values dataset(s) of this group. If no uncertainty values are in the dataset(s) the value must be the fillValue |
| 4 | maximum Uncertainty | maximumUncertainty | 1 | Float 32-bit | The maximum uncertainty value in the values dataset(s) of this group. If no uncertainty values are in the dataset(s) the value must be the fillValue |
| 5 | Time stamp | timePoint | 1 | String | Because S-102 specifies survey dates elsewhere in its structure, this value should always be the fill value: 00010101T000000Z |
The group contains an HDF5 dataset named values containing the bathymetric gridded data.
6.2.7 BathymetryCoverage feature instance group — values dataset
This dataset contains the compound data arrays containing bathymetric gridded data. These components are explained below.
For bathymetric gridded data, the dataset includes a two-dimensional array containing always the depth and under certain conditions uncertainty data. These dimensions are defined by numPointsLongitudinal and numPointsLatitudinal. By knowing the grid origin and the grid spacing, the position of every grid point and grid cell can be simply computed.
If the uncertainty for each grid cell is equal, it is not necessary to store it at each cell in the grid. The uniqueness of the uncertainty results from the equality of the attributes minimumUncertainty and maximumUncertainty of Group_001 of the BathymetryCoverage (see Table 6-7 No. 3 & 4). If the uncertainty values at the grid cells are omitted, it must be ensured that the entry of the uncertainty of the BathymetryCoverage in the Group_F is also omitted (see Table 6-3). This type of storage technique can reduce the amount of memory required for the uncertainty without loss of information. The uncertainty of each grid cell can be immediately obtained from the minimumUncertainty or maximumUncertainty attributes of Group_001 of the BathymetryCoverage.
If the uncertainty is not the same for each grid cell, it must be stored at each cell in the grid. For unknown or unused uncertainty data, it must be filled with the fillValue specified in the Group_F feature information dataset.
The grid cell values are stored in two-dimensional arrays with a prescribed number of columns (numCOL) and rows (numROW). This grid is defined as a regular grid (dataCodingFormat = 2); therefore, the depth and uncertainty values will be for each cell in the grid. The data type of the array values is a compound with one or two members.
6.2.8 Root QualityOfBathymetryCoverage
The QualityOfBathymetryCoverage container group has the same metadata attributes as BathymetryCoverage container group (see Table 6-4). The values of the attributes must also be the same as the BathymetryCoverage container group. An exception is the attribute dataCodingFormat, which must be ‘9’. The use of multiple BathymetryCoverage Feature Instance groups (different Vertical Datums) does not affect the multiplicity of the QualityOfBathymetryCoverage, which remains 0 to 1. This means that the different BathymetryCoverage Feature Instance groups share a common QualityOfBathymetryCoverage.
The QualityOfBathymetryCoverage container group contains an additional 1-dimensional array named featureAttributeTable (part=10c,table=9; part=10c,clause=9.6.2). This dataset is mandatory within the QualityOfBathymetryCoverage group. Each element of this array is a metadata record of HDF5 compound type. The fields are described in Table 6-8 below.
Table 6-8 — Elements of featureAttributeTable compound datatype
| No | Attribute | Description | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
| 1 | id | Metadata record identifier | 1 | Integer unsigned 32-bit | Each record must have a unique identifier. |
| 2 | dataAssessment | The categorization of the assessment level of bathymetric data for an area. | 0..1 | Integer unsigned 8-bit | *1: Assessed *2: Unassessed *3: Oceanic |
| 3 | featuresDetected.leastDepthOfDetectedFeaturesMeasured | Expression stating if the least depth of detected features in an area was measured. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 6.2.8, Note 1. |
| 4 | featuresDetected.significantFeaturesDetected | A statement expressing if significant features have or have not been detected in the course of a survey. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 6.2.8, Note 2. |
| 5 | featuresDetected.sizeOfFeaturesDetected | The size of detected bathymetric features in an area. | 0..1 | Float 32-bit | See Clause 6.2.8, Note 3 and Clause 6.2.8, Note 4. |
| 6 | featureSizeVar | Percentage of depth that a feature of such size could be detected. | 0..1 | Float 32-bit | Set to zero if the feature size does not scale with depth. See Clause 6.2.8, Note 3 and Clause 6.2.8, Note 4. |
| 7 | fullSeafloorCoverageAchieved | Expression stating if full seafloor coverage has been achieved in the area by hydrographic surveys. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 6.2.8, Note 5. |
| 8 | bathyCoverage | False for grid cells populated by interpolation. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 6.2.8, Note 6. |
| 9 | zoneOfConfidence.horizontalPositionUncertainty.uncertaintyFixed | The best estimate of the fixed horizontal or vertical accuracy component for positions, depths, heights, vertical distances, and vertical clearances. | 0..1 | Float 32-bit | |
| 10 | zoneOfConfidence.horizontalPositionUncertainty.uncertaintyVariableFactor | The factor to be applied to the variable component of an uncertainty equation so as to provide the best estimate of the variable horizontal or vertical accuracy component for positions, depths, heights, vertical distances, and vertical clearances. | 0..1 | Float 32-bit | |
| 11 | surveyDateRange.dateStart | The start date of the period of the hydrographic survey. | 0..1 | Date | ISO 8602:2004 date format. Complete or truncated date, see part=1,table=2. |
| 12 | surveyDateRange.dateEnd | The end date of the period of the hydrographic survey. | 0..1 | Date | ISO 8602:2004 date format. Complete or truncated date, see part=1,table=2. |
| 13 | sourceSurveyID | The survey filename or ID. | 0..1 | String | |
| 14 | surveyAuthority | The authority which was responsible for the survey. | 0..1 | String | |
| 15 | typeOfBathymetricEstimationUncertainty | The measure used to estimate the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made. | 0..1 | Enumeration | See Table 6-9. See Clause 6.2.8, Note 7. |
NOTE 1 A feature in this context is any object, whether manmade or not, projecting above the sea floor, which may be a danger for surface navigation [iho-s44]. Least depth of detected features measured does not describe the least depth of features that were actually detected during a hydrographic survey, but the ability of the survey to detect the least depth of features with a maximum uncertainty as defined in [iho-s44]. NOTE 2 A feature in this context is any object, whether manmade or not, projecting above the sea floor, which may be a danger for surface navigation [iho-s44]. Significant features detected does not describe if significant features were actually detected during a hydrographic survey, but whether the survey had the capacity to detect significant features. NOTE 3 The role of the attribute, featureSizeVar is described in Clause 3.1. The expectation is that featureSizeVar will be set to zero if the feature size does not scale with depth. As with featureSize, featureSizeVar should be ignored if significantFeatures is False. NOTE 4 When both featureSize and featureSizeVar are present, the greater of the two should be considered valid. NOTE 5 Full seafloor coverage achieved applies to both the spatial completeness of feature detection and to the spatial completeness of the measurement of the regular seafloor. The former is further specified by the complex attribute features detected; the latter by the attributes depth range maximum value and depth range minimum value. NOTE 6 The attribute bathyCoverage is especially useful in side-scan surveys which are characterized by gaps in bathymetric observations with full coverage side-scan imagery. In this case, interpolated gaps between bathymetry coverage would show fullSeafloorCoverageAchieved = True and bathyCoverage = False. However, if fullSeafloorCoverageAchieved = False, bathyCoverage must also equal False (e.g., gaps between single beam echosounder data without correlating side-scan sonar coverage). NOTE 7 Names and listed values which are not currently defined in the IHO GI Registry are subject to change upon acceptance in the Registry. | |||||
Table 6-9 — Codes defining how uncertainty of bathymetric depth was determined
| Role Name | Name | Description | Code | Remarks |
|---|---|---|---|---|
| Enumeration | S102_BatymetricUncertaintyType | An estimate of the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made. | - | |
| Value | rawStandardDeviation | Raw standard deviations of soundings that contributed to the grid cell. | 1 | - |
| Value | cUBEStandardDeviation | Standard deviation of soundings captured by a CUBE hypothesis (that is, CUBE’s standard output of uncertainty). | 2 | - |
| Value | productUncertainty | The greater of (1) standard deviation of the soundings contributing to the depth solution or, (2) the a priori computed uncertainty estimate (that is, modelled Total Vertical Uncertainty). | 3 | - |
| Value | historicalStandardDeviation | Estimated standard deviation based on historical/archive data. | 4 | - |
| Value | (fill value representing “unknown”) | (fill value when the uncertainty is an unknown layer type) | 0 | This is a “fill value” and will not be in the feature catalogue. |
6.2.9 Instance group QualityOfBathymetryCoverage.01
The QualityOfBathymetryCoverage.01 instance group has the same metadata attributes as BathymetryCoverage.01 instance group (see Table 6-6). The values of the attributes must also be the same as the BathymetryCoverage instance group.
6.2.10 Values group for QualityOfBathymetryCoverage
The values group for QualityOfBathymetryCoverage contains no metadata attributes and a single dataset named values, which is described in Clause 6.2.11.
6.2.11 Values dataset for QualityOfBathymetryCoverage
The values dataset for QualityOfBathymetryCoverage is a single two-dimensional array of unsigned integers (the same datatype and size as the “id” field in featureAttributeTable — Table 6-7). The array must have the same dimensions as the values dataset in the BathymetryCoverage feature instance (Clause 6.2.7).
Each cell in this values dataset must be populated with a value that is one of the record identifiers in the featureAttributeTable dataset or with the fill value 0 (zero).
6.2.12 Mandatory Naming Conventions
The following group and attribute names are mandatory in S-100:
Group_F
featureCode
(for S-102)
BathymetryCoverage
axisNames
BathymetryCoverage.01
QualityOfBathymetryCoverage.01
featureAttributeTable
Group_nnn
7 Data Product Delivery
7.1 Introduction
This clause describes how S-102 data will be delivered from the charting authority to the mariner.
- Units of Delivery
Exchange Set
- Transfer Size
See Clause 7.2.2.
- Medium Name
Digital Data Delivery
- Other Delivery Information
Each dataset must be contained in a physically separate, uniquely identified file on the transfer medium.
Each exchange set has a single exchange catalogue which contains the discovery metadata for each dataset.
An exchange set is encapsulated into a form suitable for transmission by a mapping called an encoding. An encoding translates each of the elements of the exchange set into a logical form suitable for writing to media and for transmission online. An encoding may also define other elements in addition to the exchange set contents (This is media identification, data extents etc. …) and may define commercial constructs such as encryption and compression methods.
If the data is transformed in S-102 it must not be changed.
This Product Specification defines the encoding which must be used as a default for transmission of data between parties.
The encoding encapsulates exchange set elements as follows:
Mandatory Elements
S-102 datasets — HDF encoding
Exchange Catalogue — the XML encoded representation of exchange set catalogue features [discovery metadata].
Optional Elements
S-102 Feature Catalogue — If it is necessary to deliver the latest Feature Catalogue to the end user it may be done using the S-102 exchange set mechanism for datasets
S-102 Portrayal Catalogue — If it is necessary to deliver the latest Portrayal Catalogue to the end user it may be done using the S-102 exchange set mechanism for datasets.
7.2 Dataset
7.2.1 Dataset management
Three types of dataset files may be produced and contained within an exchange set:
New dataset: Initial.
New edition of a dataset: Includes new information. New editions must cover at least the same area as its predecessor.
Cancellation: The dataset is cancelled and no longer available to be displayed or used.
7.2.1.1 Production of a cancellation
S-102 uses only the fileless cancellation method described in part=17,clause=17-4.4.1. In order to cancel a dataset, the cancelling authority (generally the producer of the original dataset) must:
Prepare an exchange catalogue with an S100_DatasetDiscoveryMetadata block with field values as described in Clause 7.2.1.2.
Complete other parts of the exchange catalogue as required by Clause 8.4 (for example, provide discovery metadata for a replacement dataset if such is included in the same exchange set).
Sign and distribute the exchange catalogue in a normally structured exchange set.
7.2.1.2 Metadata for cancellation
S-102 uses only the fileless cancellation method described in part=17,clause=17-4.4.1. For a cancellation, set:
fileName = fileName of the cancelled dataset
purpose = cancellation
issueDate and issueTime = the issue date and time of the cancellation
replacedData = true if and only if the cancelled dataset is replaced by another dataset; otherwise false. This attribute must be populated for a cancellation.
dataReplacement = fileName of the replacement dataset (if and only if the cancelled dataset is replaced by another dataset). This attribute must be populated when replacedData=true.
all other mandatory attributes to the same values as in the discovery metadata block for the dataset being cancelled.
7.2.2 Dataset size
S-102 delivery will take place in one form: network transfer to platform (that is, internet download). An example scenario has been provided below:
NOTE The use of 10 MB in this and other sections should be treated as informative information only. Additionally, any computed values associated with either file size limit should be treated as approximate answers. Final selection of an appropriate file size limit or grid resolution is left to the discretion of the data producer.
- Network Transfer
To minimize overall file size, the HO produces a 10 MB file for wireless transmission to marine vessels. In uncompressed form, this file would contain roughly 600 by 600 grid cells.
Table 7-1 provides general information to aid in the compilation of S-102 data for specific charting scales.
7.2.2.1 S-102 grid resolution and tiling
Table 7-1 — Informative Grid Resolution and Resulting Tile Size at Chart Scale
| Scale | Informative Grid Resolution | Resulting Tile Size @ 10 MB |
|---|---|---|
NULL (only allowed on minimum display scale where the maximum display scale = 10,000,000) | Approximate Linear Distance in Nautical Miles (M) for a 600 X 600 cell grid | |
1:10,000,000 | 900 metres | 291 X 291 |
1:3,500,000 | 900 metres | 291 X 291 |
1:1,500,000 | 450 metres | 145 X 145 |
1:700,000 | 210 metres | 68 X 68 |
1:350,000 | 105 metres | 34 X 34 |
1:180,000 | 54 metres | 17.5 X 17.5 |
1:90,000 | 27 metres | 8.7 X 8.7 |
1:45,000 | 13 metres | 4.2 X 4.2 |
1:22,000 | 6 metres | 1.9 X 1.9 |
1:12,000 | 3 metres | 1.0 X 1.0 |
1:8,000 | 2 metres | 0.6 X 0.6 |
1:4,000 | 1 metres | 0.3 X 0.3 |
1:3,000 | 1 metres | 0.3 X 0.3 |
1:2,000 | 1 metres | 0.3 X 0.3 |
1:1,000 | 1 metres | 0.3 X 0.3 |
7.2.3 Dataset file naming
Dataset naming must follow a standard pattern to give implementers greater predictability of incoming datasets (see part=17,clause=4.3). S-102 dataset naming conventions must follow these rules.
- 102YYYYØØØØØØØØØØØØ.H5
102
the first 3 characters identify the dataset as an S-102 dataset (mandatory).
YYYY
the fourth to seventh characters identify the producer code according to the Producer Code Register.
ØØØØ
the eighth to the maximum nineteenth characters are optional and may be used in any way by the producer to provide the unique file name. The following characters are allowed in the dataset name: A to Z, 0 to 9 and the special character _ (underscore).
H5
denotes an HDF5 file.
7.3 Exchange Set
The structure of an S-102 Exchange Set must be according to the structure described below, which is based on part=17,clause=4.2.
An S-102 Exchange Set must contain an Exchange Set Catalogue, CATALOG.XML, its digital signature CATALOG.SIGN, and may contain any number of S-102 conformant dataset files, support files, and Catalogue files.
All content must be placed inside a top root folder named S100_ROOT. This is the only top level root folder in an Exchange Set containing only S-100 products.
The S100_ROOT folder must contain a subfolder named S-102. This subfolder holds content specific to the S-102 Product Specification.
The S-102 subfolder must contain subfolders for the component dataset files (DATASET_FILES) and Catalogues (CATALOGUES) as required.
The required Exchange Set Catalogue XML document instance must be named CATALOG.XML and placed in the S100_ROOT folder, together with its digital signature (CATALOG.SIGN) file. All other digital signatures are included within their corresponding resource metadata records in the CATALOG.XML.
Support files are not allowed in S-102 exchange sets for this edition of S-102.
7.4 Exchange Catalogue
The Exchange Catalogue acts as the table of contents for the Exchange Set. The Catalogue file of the Exchange Set must be named CATALOG.XML. No other file in the Exchange Set may be named CATALOG.XML. The contents of the Exchange Catalogue are described in Section 8.
7.5 Data integrity and encryption
part=15 defines the algorithms for compressing, encrypting and digitally signing datasets based on the S-100 Data Model. The individual Product Specifications provide details about which of the elements are being used and on which files in the dataset.
7.5.1 Use of compression
The data producer decides if compression will be used on the S-102 product files (HDF5). It is expected that a hydrographic office will make a policy decision and that all the S-102 datasets from the producer will be either compressed or uncompressed.
It is recommended to compress all the dataset files, for example HDF5 files. The ZIP compression method defined in part=15,clause=5.2 must be applied to the product files.
7.5.2 Use of data protection
It is recommended to encrypt all the dataset files, for example HDF5. The encryption method defined in part=15 must be applied.
7.5.3 Use of digital signatures
Digital signatures shall be used on all files included in a S-102 compliant Exchange Set to meet the requirements of IMO resolution MSC.428(98) to reduce cyber security risks among users, especially when used in navigations systems at sea. The recommended signature method is defined in part=15.
The digital signature information is encoded in the corresponding discovery block in the exchange catalogue for each file included in the Exchange Set.
8 Metadata
8.1 Introduction
The Metadata elements used in the Bathymetric Surface product are derived from S-100 and from [iso-19115-1] and [iso-19115-2]. Optionally additional metadata may be derived from [iso-ts-19130] and [iso-ts-19130-2] especially metadata relating to the sonar equipment which may have been used to acquire the bathymetric data.
S-102 metadata is encoded in two places:
Metadata used for the discovery, identification, and use of S-102 datasets in S-100-based navigations systems (specifically, an S-100-capable ECDIS) is encoded in the exchange catalogue. This metadata conforms to S-100 Part 17, with product-specific restrictions added.
Metadata required by the S-100 HDF5 encoding (part=10c) and product-specific metadata defined by this product specification are encoded at various levels in the HDF5 group hierarchy, as specified by part=10c or Clause 6.2.
8.2 Exchange Set metadata
For information exchange, there are several categories of metadata required: metadata about the overall Exchange Catalogue, metadata about each of the datasets contained in the Catalogue.
Figure 8-1 depicts the relationships of exchange set elements (datasets and feature/portrayal catalogues) and exchange set metadata. This figure is derived from part=17,figure=2 with relationships not applicable to S-102 omitted.
Figure 8-2 depicts the structure of the exchange catalogue and its component discovery metadata blocks. The structure is the same as in part=17.
More detailed information about the various classes is shown in Figure 8-3 with further description in Table 8-1 to Clause 8.8.2. In the cases in which classes are used without modification, refer to part=17 for their descriptions.
The discovery metadata classes have numerous attributes which enable important information about the datasets to be examined without the need to process the data (e.g., decryption, decompression, loading). Other Catalogues can be included in the Exchange Set in support of the datasets such as Feature and Portrayal.
Figure 8-1 — Components and associated metadata for the S-102 exchange set (part=17,figure=2 with items not used by S-102 omitted)
Figure 8-2 — Relationship between exchange catalogue, discovery metadata, and dataset (part=17,figure=6 with items not used by S-102 omitted)
Figure 8-3 — S-102 Exchange Set Class Details (part=17,figure=7 with items not used by S-102 omitted)
The following clauses define the mandatory and optional metadata needed for S-102. In some cases, the metadata may be repeated in a national language. If this is the case it is noted in the Remarks column.
The XML schemas for S-102 exchange catalogues will be available from the IHO Geospatial Information (GI) Registry and/or the S-100 GitHub site (https://github.com/IHO-S100WG).
The S-102 exchange catalogue uses the S-100 exchange catalogue schemas which are available from the S-100 schema server at https://schemas.s100dev.net (downloadable archives are also available on the site for offline use). Implementation of the S-102-specific constraints described in following clauses below is left to developer decision as it can be done in various ways depending on implementation frameworks and the requirements of production or application software.
8.3 Language
The exchange language must be English.
Character strings must be encoded using the character set defined in [iso-10646-1], in Unicode Transformation Format-8 (UTF-8). A BOM (byte order mark) must not be used.
8.4 S100_ExchangeCatalogue
Each Exchange Set has a single S100_ExchangeCatalogue which contains meta information for the data in the Exchange Set.
S-102 uses S100_ExchangeCatalogue without modification.
8.4.1 S100_ExchangeCatalogueIdentifier
S-102 uses S100_ExchangeCatalogueIdentifier without modification.
8.4.2 S100_CataloguePointOfContact
S-102 uses S100_CataloguePointOfContact without modification.
8.5 S100_DatasetDiscoveryMetadata
Dataset discovery metadata in S-102 restricts certain attributes and roles as described in Table 8-1. Optional S-100 attributes which are mandatory in S-102 are indicated in the Remarks column.
Table 8-1 — S100_DatasetDiscoveryMetadata parameters
| Role name | Name | Description | Mult | Type | Remarks |
|---|---|---|---|---|---|
Class | S100_DatasetDiscoveryMetadata | Metadata about the individual datasets in the Exchange Catalogue | - | - | The optional S-100 attributes updateNumber, updateApplicationDate, referenceID, and temporalExtent are not used in S-102. |
Attribute | fileName | Dataset file name | 1 | URI | See part=1,clause=4.6 |
Attribute | description | Short description giving the area or location covered by the dataset | 0..1 | CharacterString | For example a harbour or port name, between two named locations, etc. |
Attribute | datasetID | Dataset ID expressed as a Maritime Resource Name | 0..1 | URN | The URN must be an MRN. |
Attribute | compressionFlag | Indicates if the resource is compressed | 1 | Boolean | True indicates a compressed dataset resource. |
Attribute | dataProtection | Indicates if the data is encrypted | 1 | Boolean | True indicates an encrypted dataset resource. |
Attribute | protectionScheme | Specification of method used for data protection | 0..1 | S100_ProtectionScheme | Populate if and only if dataProtection = True. |
Attribute | digitalSignatureReference | Specifies the algorithm used to compute digitalSignatureValue | 1 | S100_SE_DigitalSignatureReference | |
Attribute | digitalSignatureValue | Value derived from the digital signature | 1..* | S100_SE_DigitalSignature | see part=15,clause=15-8.11.3 |
Attribute | copyright | Indicates if the dataset is copyrighted | 1 | Boolean | True indicates the resource is copyrighted. |
Attribute | classification | Indicates the security classification of the dataset | 1 | Class | Mandatory in S-102
|
Attribute | purpose | The purpose for which the dataset has been issued | 1 | S100_Purpose | Mandatory in S-102 |
Attribute | notForNavigation | Indicates the dataset is not intended to be used for navigation | 1 | Boolean | True indicates the dataset is not intended to be used for navigation. |
Attribute | specificUsage | The use for which the dataset is intended | 0..1 | MD_USAGE>specificUsage (character string) | - |
Attribute | editionNumber | The edition number of the dataset | 1 | Integer | When a data set is initially created, the Edition number 1 is assigned to it. The Edition number is increased by 1 at each new Edition. Edition number remains the same for a re-issue. |
Attribute | issueDate | Date on which the data was made available by the Data Producer | 1 | Date | - |
Attribute | issueTime | Time of day at which the data was made available by the Data Producer | 0..1 | Time | The S-100 datatype Time |
Attribute | boundingBox | The extent of the dataset limits | 1 | EX_GeographicBoundingBox | Mandatory in S-102 |
Attribute | productSpecification | The Product Specification used to create this dataset | 1 | S100_ProductSpecification | |
Attribute | producingAgency | Agency responsible for producing the data | 1 | CI_Responsibility>CI_Organisation | |
Attribute | producerCode | The official IHO Producer Code from S-62 | 1 | CharacterString | Mandatory in S-102 |
Attribute | encodingFormat | The encoding format of the dataset | 1 | S100_EncodingFormat | The only allowed value is HDF5 |
Attribute | dataCoverage | Provides information about data coverages within the dataset | 1..* | S100_DataCoverage | Mandatory in S-102 |
Attribute | comment | Any additional information | 0..1 | CharacterString | - |
Attribute | defaultLocale | Default language and character set used in the dataset | 0..1 | PT_Locale | In absence of defaultLocale, the language is English, and the character set is UTF-8. |
Attribute | otherLocale | Other languages and character sets used in the dataset | 0..* | PT_Locale | |
Attribute | metadataPointOfContact | Point of contact for metadata | 0..1 | CI_Responsibility>CI_Individual | Only if metadataPointOfContact differs from producingAgency |
Attribute | metadataDateStamp | Date stamp for metadata | 0..1 | Date | May or may not be the issue date |
Attribute | replacedData | Indicates if a cancelled dataset is replaced by another data file(s) | 0..1 | Boolean | See note following part=17,table=S100_DatasetDiscoveryMetadata |
Attribute | dataReplacement | Dataset name | 0..* | CharacterString | A dataset may be replaced by 1 or more datasets. |
Attribute | navigationPurpose | Classification of intended navigation purpose (for Catalogue indexing purposes) | 1..3 | S100_NavigationPurpose | If Product Specification is intended for creation of navigational products, this attribute should be mandatory. |
Role | resourceMaintenance | Information about the frequency of resource updates, and the scope of those updates | 0..1 | MD_MaintenanceInformation | S-100 restricts the multiplicity to 0..1 and adds specific restrictions on the ISO 19115 structure and content. See part=17. |
8.5.2 S100_DataCoverage
S-102 uses S100_DataCoverage without modification, but with additional remarks and changes to the multiplicity.
Table 8-2 — S100_DataCoverage parameters
| Role name | Name | Description | Mult | Type | Remarks |
|---|---|---|---|---|---|
Class | S100_DataCoverage | A spatial extent where data is provided along with the display scale information for the provided data | - | - | This field is used by user systems as part of the data loading and unloading algorithms, and it is strongly encouraged that Product Specifications mandate the use of one or more of the displayScale provided as part of S100_DataCoverage. |
Attribute | boundingPolygon | A polygon which defines the actual data limit | 1 | EX_BoundingPolygon | |
Attribute | temporalExtent | Specification of the temporal extent of the coverage | 0 | S100_TemporalExtent | The temporalExtent is not used in S-102. |
Attribute | optimumDisplayScale | The scale at which the data is optimally displayed | 0..1 | Integer | Example: A scale of 1:25000 is encoded as 25000 |
Attribute | maximumDisplayScale | The maximum scale at which the data is displayed | 0..1 | Integer | |
Attribute | minimumDisplayScale | The minimum scale at which the data is displayed | 0..1 | Integer | |
Attribute | approximateGridResolution | The resolution of gridded or georeferenced data (in metres) | 1..2 | Real | Mandatory in S-102 |
NOTE boundingPolygon is restricted to a single GML Polygon with one exterior and 0 or more interiors expressed as Linear Rings using SRS EPSG:4326. The exterior and optional interiors shall be composed of a closed sequence of >=4 coordinate positions expressed individually or as a list (posList). The GML polygon shall have a valid GML identifier. | |||||
8.5.3 S100_Purpose
S-102 uses S100_Purpose without modification, but with a restriction on the allowed values.
Table 8-3 — S100_Purpose
| Role name | Name | Description | Code | Remarks |
|---|---|---|---|---|
Enumeration | S100_Purpose | The purpose of the dataset | - | The S-100 values update, reissue, and delta are not used in S-102. |
Value | newDataset | Brand new dataset | 1 | No data has previously been produced for this area. |
Value | newEdition | New edition of the dataset or Catalogue | 2 | Includes new information which has not been previously distributed by updates. |
Value | cancellation | Dataset or Catalogue that has been cancelled | 5 | Indicates the dataset or Catalogue should no longer be used and can be deleted. |
8.5.4 S100_EncodingFormat
S-102 uses S100_EncodingFormat with a restriction on the allowed values to permit only the S-100 HDF5 format for S-102 datasets.
Table 8-4 — S100_EncodingFormat parameters
| Role name | Name | Description | Code | Remarks |
|---|---|---|---|---|
Enumeration | S100_EncodingFormat | The encoding format | - | The only value allowed in S-102 is “HDF5”. |
Value | HDF5 | The HDF5 data format as defined in part=10c | 3 | - |
8.5.5 S100_ProductSpecification
S-102 uses S100_ProductSpecification without modification, but with additional remarks and changes to the multiplicity.
Table 8-5 — S100_ProductSpecification parameters
| Role name | Name | Description | Mult | Type | Remarks |
|---|---|---|---|---|---|
Class | S100_ProductSpecification | The Product Specification contains the information needed to build the specified product. | - | - | - |
Attribute | name | The name of the Product Specification used to create the datasets | 1 | CharacterString | The name in the GI Registry should be used for this field. |
Attribute | version | The version number of the Product Specification | 1 | CharacterString | TR 2/2007 specifies versioning of Product Specifications |
Attribute | date | The version date of the Product Specification | 1 | Date | - |
Attribute | productIdentifier | Machine readable unique identifier of a product type | 1 | CharacterString | For S-102, this identifier is “S-102” (without quotes). |
Attribute | number | The number used to lookup the product in the Product Specification Register of the IHO GI registry | 1 | Integer | For IHO Product Specifications, these numbers should be taken from the IHO Product Specification Register in the IHO GI Registry. |
Attribute | compliancyCategory | The level of compliance of the Product Specification to S-100 | 0..1 | S100_CompliancyCategory | See part=4a,clause=4a-5.5 and Clause 8.5.6 below. |
8.5.6 S100_CompliancyCategory
S-102 exchange sets conforming to this edition of S-102 and using a CRS from the EPSG registry may be encoded as category 3 or 4 when the compliancyCategory metadata attribute is populated. Because S-98 interoperability assumes category4 datasets, category4 may be used for test purposes, though the absence of test datasets and of a published IHO interoperability catalogue mean this edition of S-102 does not yet qualify for category4. Given the uncertainty about interoperability testing requirements and availability of test datasets, the S-100 WG chair and S-102 PT chair should be consulted for up-to-date guidance.
Table 8-6 — S100_CompliancyCategory
| Role Name | Name | Description | Code | Remarks |
|---|---|---|---|---|
Enumeration | S100_CompliancyCategory | - | - | S-102 should use category3 or category4, subject to the guidance provided in Clause 8.5.6. |
Value | category3 | IHO S-100 compliant with standard encoding | 3 | Qualifies as category2; plus “The Product Specification uses only an encoding method defined in part=10;and!part=4a,clause=5.5.3” |
Value | category4 | IHO S-100 and IMO harmonized display compliant | 4 | Qualifies as category3; plus additional requirements, including a portrayal catalogue, cybersecurity (digital signatures and encryption), test material, use of a CRS from the EPSG Registry, and compliance with the IHO S-98 interoperability catalogue. part=4a,clause=5.5.4 |
8.5.7 S100_ProtectionScheme
S-102 uses S100_ProtectionScheme without modification.
8.6 MD_MaintenanceInformation
S-102 uses MD_MaintenanceInformation without modification.
8.7 MD_MaintenanceFrequencyCode
S-102 uses MD_MaintenanceFrequencyCode without modification.
8.8 S100_CatalogueDiscoveryMetadata
S-102 uses S100_CatalogueDiscoveryMetadata without modification.
8.8.1 S100_CatalogueScope
S-102 uses S100_CatalogueScope without modification.
8.8.2 PT_Locale
S-102 uses PT_Locale without modification. The class PT_Locale is defined in [iso-19115-1]. LanguageCode, CountryCode, and MD_CharacterSetCode are ISO codelists which are defined in a codelists file which is part of the S-100 Edition 5.2.0 schema distribution.
8.9 Certificates and Digital Signatures
The classes S100_SE_CertificateContainerType (part=15,clause=8.11.1), S100_SE_DigitalSignatureReference (part=15,clause=8.11.7), and S100_SE_DigitalSignature are defined in part=15 and implemented in the S-100 generic schemas.
In accordance with part=15, only the ECDSA algorithm is allowed from the S100_SE_DigitalSignatureReference enumeration.
S-102 uses S100_SE_DigitalSignature without modification. As stated in part=15,clause=15-8.11.3:
“The class S100_SE_DigitalSignature is realized as one of either S100_SE_SignatureOnData (a digital signature of a particular identified resource) or an additional digital signature defined using the class S100_SE_AdditionalSignature, each of which is either a S100_SE_SignatureOnData or S100_SE_SignatureOnSignature element as described in part=15,clause=8.8. part=17 metadata thus allows for multiple digital signatures, a single mandatory S100_SE_SignatureOnData and any number of additional signatures, either of the data or other signatures.”
Annex A
Data Classification and Encoding Guide
A.1 Features
A.1.1 BathymetryCoverage
Table A-1 — BathymetryCoverage feature parameters
Term: Bathymetry Coverage | |||
IHO Definition: A set of value items required to define a dataset representing a depth calculation and its associated uncertainty. | |||
Primitive: S100_IF_GridCoverage | |||
| Attribute | Allowable Encoding Value | Type | Multiplicity |
|---|---|---|---|
depth | Must be in decimal metres with resolution not to exceed 0.01 metres | real (32-bit Float) | 1 |
uncertainty | Must be in decimal metres with resolution not to exceed 0.01 metres | real (32-bit Float) | 0..1 |
A.1.2 QualityOfBathymetryCoverage
Table A-2 — QualityOfBathymetryCoverage feature parameters
Term: Quality Of Bathymetry Coverage. | |||
IHO Definition: A set of references to value records that provide localised information about depth, uncertainties, and bathymetry coverage metadata. | |||
Primitive: S100_IF_GridCoverage | |||
| Attribute | Constraint | Type | Multiplicity |
|---|---|---|---|
iD | Each record must have a unique identifier. | unsigned 32-bit Integer | 1 |
A.2 Feature Attributes
A.2.1 BathymetryCoverage
Table A-3 — BathymetryCoverage feature attribute parameters
IHO Definition: depth. The vertical distance from a given water level to the bottom [[iho-s32]]. |
Unit: metres |
Resolution: 0.01 |
Remarks:
|
IHO Definition: uncertainty. Estimate characterising the range of values within which the true value of a measurement is expected to lie as defined within a particular confidence level. It is expressed as a positive value. |
Unit: metres |
Resolution: 0.01 |
Remarks:
|
A.2.2 QualityOfBathymetryCoverage
Table A-4 — QualityOfBathymetryCoverage feature attribute parameters
IHO Definition: iD. Meta data record identifier for QualityOfBathymetryCoverage |
Unit: |
Resolution: |
Remarks: |